S3イベント通知 vs EventBridge 処理漏れ率を比べてみた2

先日、以下エントリを書きました。

S3バケットにファイルがアップロードされたのを検知し、それをトリガーに別の処理を走らせる方法として、S3イベント通知機能とEventBridge(CloudWatch Events)と2つの方法があり、それぞれの処理漏れ率を比べてみたエントリです。

処理漏れ率は、1万個のファイルをアップロードして比べたところ、どちらも0%でした。そこで今回はさらにファイル数を増やして 100万個のファイル で検証してみました。

検証方法

前回と同じです。同一S3バケットに対して2つの処理系統を用意します。

• S3バケット → S3イベント通知 → SNSトピック
• S3バケット → CloudTrailオブジェクトレベル認証 → EventBridge → （上記処理で使っているのとは別の）SNSトピック

このS3バケットに対して、オブジェクトを100万個作成します。 SNSトピックのCloudWatchメトリクスNumberOfMessagesPublishedにて発行されたメッセージ数を確認します。

検証結果

• S3イベント通知 → 100万メッセージ
• EventBridge → 100万20メッセージ

!??

想定外の結果でした。以下のような結果を予想していました。

• S3イベント通知はまれに処理漏れが発生するとドキュメントにもあるので、処理漏れ 0%もしくは多少発生するのかな
• EventBridgeは最大 24 時間にわたり再配信を試みるので、処理漏れは起きないのでは

EventBridgeはイベント重複が起きえる

ドキュメントに記載がありました。

• 1 つのイベントに応じてルールが複数回トリガーされました。EventBridge で、ルールのトリガーまたはターゲットへのイベントの提供で何が保証されますか。 | EventBridgeユーザーガイド トラブルシューティング

まれに、単一のイベントまたはスケジュールされた期間に対して同じルールを複数回トリガーしたり、特定のトリガーされたルールに対して同じターゲットを複数回起動したりする場合があります。

S3イベント通知でもイベント重複が起きえる

今回は発生しませんでしたが、S3イベント通知でもイベント重複が起きるようです。

• 同じ Amazon S3 イベントの Amazon SQS で重複したメッセージが表示されるのはなぜですか? | AWS ナレッジセンター

Amazon S3 は、組み込みのバックオフと再試行メカニズムを使用して、高い信頼性で通知を配信するように設計されています。まれに、再試行メカニズムによって同じオブジェクトイベントの通知が重複する場合があります。

まとめ

• S3バケットにオブジェクトがアップロードされたことを起点になにかしらの処理を実行したい場合、その方法がふたつ存在する。S3イベント通知機能とEventBridge。
• 両者の処理漏れ率を検証するため100万個のファイルをアップロード。するとEventBridge側で処理漏れどころか処理重複が発生した。
• S3イベント通知機能とEventBridge、どちらも処理重複（イベント重複）が起きえる。後段の処理は冪等性のある処理にしましょう。